1. Field of the Invention
This invention is related to the field of backup and restore of computer systems.
2. Description of the Related Art
Various software tools exist for backing up computer systems and restoring backup data to computer systems (referred to as “backup software”). Such backup software is provided to permit recovery, at least to the most recent backup state, from a failure. The failure may be due to user error, hardware failure in the backed-up computer system, other disaster situations originating outside the computer system that cause data loss such as by damaging the computer system, or a combination of the above. User error may include activities such as accidental file deletion, file corruption, or erroneous file content change.
Some operating systems maintain a database describing the computer system configuration. For example, recent versions of the Windows™ operating system from Microsoft Corp. (Redmond, Wash.) include the Registry. The Registry is a centralized, hierarchical database storing computer system configuration information. The hierarchy is specified as a set of “keys” that identify information in the database. Entries associated with the keys contain the information. The Registry is stored in one or more files on the computer system. Thus, the Registry is generally backed-up along with other computer system data during a backup operation.
Typically, when a restore operation is to be performed to a computer system, either the operating system is already installed on the computer system prior to initiating the restore operation or the operating system is installed as part of the overall restore operation (referred to as an automated system restore operation). In an automated system restore operation, the operating system is installed first from an installation media before attempting to restore the backup data. In either case, there is an instance of the Registry maintained by the operating system on the computer system and an instance of the Registry in the backup data. Merely overwriting the instance on the computer system with the instance in the backup data does not lead to correct results.
For example, the instance of the Registry on the computer system may have information pertinent to the restore operation. In some cases, if a file is open on the computer system and a backed-up copy of the file is being restored in the restore operation, a copy of the file is made on the computer system with a different file name or in a different directory and the Registry is updated to cause the backed-up file to be restored with its original file name/location on the next reboot. Particularly, one or more keys in the Registry may identify the files to be restored on the next reboot. In other cases, it is desirable to retain certain keys of the Registry instance on the computer system if there are differences between that Registry instance and the instance in the backup data. For example, if the computer system to which the restore is being performed is not the same computer system from which the backup was made, some keys of the Registry instance on the computer system may be different from corresponding keys of the Registry instance in the backup data due to differences in the new computer system versus the original computer system.
Originally, backup software “hard-coded” the Registry keys that were not to be restored from the backup instance (instead using the keys from the instance on the computer system). Unfortunately, as the operating system evolved, the list of which Registry keys were not to be restored changed. Thus, in many cases, an update of the operating system also required an update to the backup software to change the hard-coded list of Registry keys.
Subsequently, two keys were added to the Registry to identify the keys not to restore. The two keys are referred to as “KeysNotToRestore” and “AsrKeysNotToRestore”. The AsrKeysNotToRestore is used if an automated system restore operation is being performed, and takes precedence over the KeysNotToRestore in such restore operations for any conflicting definitions between the two keys. The backup software reads the KeysNotToRestore and optionally the AsrKeysNotToRestore. These two keys may be used to merge the identified keys from the Registry instance on the computer system with the other keys from the Registry instance in the backup data. The merged Registry instance is then restored to the computer system.
Unfortunately, in some cases, the above restoration mechanism loses certain hardware-specific information that may result in the user feeling that a correct restore has not occurred. Such situations occur when the restore operation is performed to a computer system that includes the same hardware as the computer system from which the backup was made. Particularly, certain hardware-specific keys are not captured using the above mechanisms. These hardware-specific keys may cause incorrect operation if restored to a system that does not include the same hardware. Accordingly, the KeysNotToRestore/AsrKeysNotToRestore mechanism relies on Plug 'n Play to generate the hardware-specific keys with appropriate settings for the computer system to which the restore is performed, and does not restore these keys from the backed-up Registry.
An example in which hardware-specific keys are lost in the KeysNotToRestore/AsrKeysNotToRestore mechanism occurs in a laptop computer system that has two network interface cards (NICs). Laptop computer systems often have one wireless NIC for use when the laptop is away from its docking station and another NIC for communicating through the docking station on a wired network. The wireless NIC may use dynamic host configuration protocol (DHCP) to obtain TCP/IP settings, but the other NIC may have fixed TCP/IP settings (e.g. a fixed IP address) bound to the NIC in the Registry. If the restore operation is to a computer system that includes the same hardware, it is desirable to capture the TCP/IP settings and restore them.
In another example, certain keys may bind a specific device driver to a hardware device. The operating system may also have a driver that can be used for the hardware device, but the user may prefer a different driver (e.g. a manufacturer-supplied driver that has more features). When the operating system is installed on the computer system for performing the restore operation, the operating system's driver is associated with the hardware device. If the restore is being performed to different hardware, using the operating system driver is typically the best course of action. However, if the restore is being performed to the same hardware, the driver indicated in the Registry instance in the backup data may be desired. Other examples of hardware-specific settings that are often lost include display settings (which sometimes are bound to the particular display hardware in the Registry) or other programmable hardware settings that are bound to a hardware device in the Registry.